User talk:Brettz9/Array merge
Is this function really worth it? array_merge(foo, bar, baz) Array.prototype.concat.call(foo, bar, baz), but much slower. I think it would be more useful to create an 'array tricks' page. — Twey 12:57, 18 October 2008 (UTC) : Hi. I took into account your point about speed and sped the code up a bit (thanks for pointing that out, and you're welcome to speed it up further if you can), but the point of the functions in this category is that they mirror the PHP functions of the same name. The idea is that those familiar with those convenient and simpler functions can use them (e.g., those of us who learned PHP and now wish to learn JavaScript), instead of being troubled to think about or even understand what the more complex call() method is achieving (of course, it's good to understand the native features of JavaScript, but that's not the point here). : You are more than welcome to use the rest of the site for array tricks (please do), but this section aims to mirror the functions' behavior at http://php.net/manual/en for the sake of those already comfortable with the behavior in that language (and/or for those who prefer such simplicity). Of course, using the native JavaScript functions alone will probably often lead to a faster behavior (just as using say assembly language could perhaps speed things up for those familiar with it), but the PHP functions are both simple, and in many cases (though admittedly not in this case) offer a quick shortcut which would require a much greater amount of JavaScript code. —Preceding unsigned comment added by 74.220.207.195 (talk • ) 09:35, 18 October 2008 ::My point was not the speed of the code but rather the fact that the code is only one statement to begin with. There's no point creating a new function to do such a simple thing. ::Javascript is a much more powerful language than PHP and as a result it usually takes less code (or at least less unpleasant code) to accomplish the equivalent — if you utilise it as Javascript. So long as you try to write PHP code in Javascript, you will indeed end up with rather a lot of redundant and ugly code. Unfortunately, the solution to learning a new language isn't to make it mimic as closely as possible a less powerful language already in your grasp, or there would be no programming languages but C :) ::There are some functions in the PHP standard library that contain features not native to Javascript, which takes a somewhat more minimalistic approach, but if you wish to build a library of these then it should be done in a Javascript style. None of the functions here apart from the change-key-cases one do anything other than clutter up the global namespace (considered acceptable in PHP, but generally regarded as a horror of coding in every language with some form of namespacing support), and even that one has rather dubious potential use cases. Frankly, I'm in favour of scrapping the whole section, and have said as much in the category talk page (where this discussion is headed). ::— Twey 12:57, 18 October 2008 (UTC) ::: First of all, I started this wiki in order to be able to do this. My co-founder had no problem with this either. The popularity of the JavaScript Equivalents for PHP blog ( http://kevin.vanzonneveld.net/techblog/article/phpjs_namespaced/ ) should be an indication that this is not some obscure interest, even if purists (or language snobs) might look down on it. I have clearly put this in its own category, so the rest of the wiki offers plenty of freedom to focus on other items related to JavaScript. I'm surprised how freely people feel to delete others' work--work which they could have left well alone (or to which they could have simply appended their reservations). ::: Secondly, your statement that it takes less code to use JavaScript than PHP code is completely not true. As the well-respected JavaScript expert and author, Douglas Crockford, points out, JavaScript was standardized early on without so many utility functions: http://javascript.crockford.com/remedial.html . You are correct that JavaScript is very powerful, and offers features which PHP does not (and is often more flexible as well); but that does not detract from the utility of mapping functions over from one language to another, both for the reduction of coding required as well as to reduce the learning curve for those familiar with PHP (and who are always welcome to inspect and adjust the PHP-JS implementation). The functions offered here might not have all been that much more succinct, but another point was to map out the full library for the sake of those already familiar with it. The fact that there are thousands of PHP functions should be an indication that its libraries can achieve some things succinctly which JavaScript cannot (achieve succinctly). ::: Thirdly, as far as namespacing, as with the JavaScript equivalents project ( http://kevin.vanzonneveld.net/techblog/article/phpjs_namespaced/ ), I felt that it would be best to offer the functions in the familiar non-namespaced form, and allow others to namespace it themselves if they so wished (as I do in my own projects and paid work). ::: If you want to offer opinions of "correct" practices, you can always describe them at Wikipedia. I don't see why I cannot have a community space for this project, especially given that I was the one who started it!! ::: (Brettz9 (I have to log in via a proxy due to Wikia being blogged in the country where I am, so that is why I am not logged in under my account, nor have I been able to maintain the site as I would like, such as to protest such changes as were made.) :::: If you really must do it, then it really belongs in a separate 'PHP-Javascript' wiki, not a general Javascript wiki. ::::: I had a hard enough time to get the Wikia folks to approve of a general JavaScript wiki. I'm doubtful I can get everything moved here. And, I haven't reviewed the guidelines for a while, but doesn't policy (which does not violate Wikia policy) get determined by the person(s) who starts the wiki? :::::: I suspect, then, that this is the real problem: Wikia do not wish to approve such a specific wiki. In that case, creating a general-purpose wiki and proceeding to use it to host the specific and only loosely-related content instead of the general-purpose content the Wikia staff no doubt had in mind when they approved the wiki, and thereby degrading the on-topic wiki content, seems a tad dishonest. I think that in this case it comes down to common sense, rather than wiki-specific policy. ::::::: Wow, how can I respond to this kind of accusation? I guess I should take off all of the photos of myself that I put here glorifying myself, promoting my own business, etc. It was such a terrible thing that I did--to start a wiki which served as an umbrella for anyone to add their own content, and then proceed to add some specific content myself. What evil. :::::::: Personally, I would feel that sort of content to be less harmful. :::: It deals with the relationship between Javascript and PHP, and is therefore outside the scope of this wiki. I would have left it alone if it were understood that these are merely a shortcut for those who know PHP, don't have the time to learn the language, and just want to 'get it done', but I am afraid that as a resource there is a strong likelihood that when it has enough information to be useful, a lot of newbies will be reading this wiki, and it would defeat the point of 'yet another resource' if it contained bad information and code that might lead newbies into believing that this is the way Javascript code is meant to be written. We have W3Schools for that purpose already. :::: As I believe I pointed out already, there are indeed many more functions in the PHP standard library than in Javascript, since PHP takes a 'stuff it all in' approach whereas Javascript prefers to be more minimalist. ::::: While sometimes I wish Mozilla, etc. made all of the functions available through some global object, PHP-JavaScript efforts makes it easy to pick and choose the items one wishes. :::: I was of course talking about the languages themselves and not their standard libraries when I made that assertion. However, it's likely that one of the large 'frameworks' has the majority of the functions you seek. ::::: I frankly haven't looked around, but I'm more interested in sticking to something I'm familiar with wherever possible. :::::: As I believe I've said before, this is not a solution to anything. ::::::: There is little difference between a framework which uses PHP as a base, and a framework which creates its own vocabulary. Yes, the PHP one may have some duplication, but it is not harming anyone to use them, just as it is not harming anyone by using a framework. Thankfully, there are plenty of useful projects that got off of the ground without the permission of purists (frameworks themselves might not exist if puerilism/purism had its way). :::::::: Nice pun! But no, there is a difference, because JavaScript already has a fairly specific style of programming, and features to support that style. Attempting to force the PHP style onto that is kind of like trying to write C code in Haskell. It's doomed to failure, and will eventually produce some really horrible code. ::::::::: I think we have to just agree to disagree here. :::::: The only advantage I can see in these functions is that it might help people who come from PHP to learn to write Javascript code. It's like saying 'I refuse to learn algebra, I'm going to stick with concrete numbers because I'm familiar with them'. It doesn't solve the problem, it's merely pretending it isn't there. ::::::: Extending your analogy, it's like ridiculing someone using JavaScript because it will be compiled by a C or Java engine anyways, and one should therefore just use C or Java. Ever hear of a tool? Look man, no one is discouraging people from learning the native functions. If you can find a little tolerance, you can allow for people to use different styles. If this can help someone get started with JavaScript, then they have the option to drop the scaffolding if they so choose. And helping people from a PHP background to learn JavaScript code is certainly not a reason to scoff at. I don't think the web or coding is only for professionals, nor do I think that professionals must be forced into a herd mentality. :::::::: Not at all. Using JavaScript is worthwhile because it's a higher-level and more powerful language than C or Java. Attempting to port the PHP interface to JavaScript is kind of like writing C, but using only inline assembly for all the functions. You're denying yourself features, not adding them. You may say that no-one is discouraging people from learning to use JavaScript properly, but the truth is that in a fairly real way, that's exactly what's happening. Having bad code on a site that's attempting to educate people about the language provides a very bad example and a suggestion that we endorse such code. If a newbie trusts us enough to base their learning on materials provided by us, and they come across a bunch of code written in PHP style, they're likely to come to the conclusion that PHP style is better than JavaScript style, and that it's therefore good style to imitate it. Now, the only style I can think of right now that's worse than PHP style is COBOL style, so... ::::::::: As with all discussions of style, there are differences of opinion. And again, I'm not the only one working on this idea, so I'm not alone in favoring this approach. :::: For those that don't, as I said originally, please do feel free to implement them for the information of others, but they should be done in a Javascript style for serious use in Javascript. If it's a quick hack the user is looking for then it may be acceptable to duplicate the PHP functions in this manner, but such code has no place in a reference designed to teach and help people to code well. ::::: That wasn't the purpose of this wiki when I set it up. There's already http://developer.mozilla.org which aims to be a general resource and already has vastly more resources on JavaScript there. My intention (as I recall indicating in my original Wikia appeal) was to add code snippets, etc.--not to create yet another reference or tutorial. :::::: As far as I'm aware, this is a general-purpose Javascript wiki. My own vision of this was as a free-to-edit general-purpose collection of resources for all levels — from tutorials (both introductory-level and guides to getting started with various technologies and methodologies) to snippets of code and information to help more advanced users on their way to applying Javascript more productively and elegantly to their problems, with more in-depth information available for reference along the road. ::::::: Firstly, what is the relevance of your own vision? This is not your wiki, dude. Secondly, there are no general purpose resources--there is only a grouping of special purpose resources. Your code snippets might be special purpose to me, and mine might be special to you. In a harmonious society, you can have your sphere, and I can have mine. I haven't been populating other pages with these snippets--they are in their own category! Until such time as my own special category gets its own wiki, I believe it fits fine under the more general umbrella. :::::::: Again, that is not wiki-like thinking. Founders and admins are not meant to have ultimate authority in a wiki like they do in a more static site. It's a democracy. 'General-purpose' is defined by the premise of the wiki: JavaScript. JavaScript information, tutorials, &c. are therefore general-purpose; a specific library is special-purpose (although, again, if it were good code or made clear that it is not endorsed as good code, there's no reason why it shouldn't have its own corner of the wiki; this is the reason I have no problem with keeping it here in your user pages, and I'm not sure why you do). ::::::::: While that came out sounding a bit too harsh, my saying this was clearly in the context of you completely disregarding, from my point of view, my own vision for a part of the wiki (even accusing me of dishonesty) (and Wikia is founder-based too, not necessarily NPOV, etc. too), insisting you are the sole authority on good code here, and then expecting me to honor your vision. It calls to mind the stories of thieves suing for the injuries they received in breaking into someone's home! (Ok, now I'm exaggerating again, but still). ::::::::: In any functioning democracy, it is not only the rule of the majority that works--but a respect for diversity and rights of individuals to operate within their own spheres; that's why democracies have life-time judges on the Supreme Court of the U.S., for example, to correct the tendency of the masses to want to swamp away the rights of its minorities--or why small states within the nation are given disproportional representation through the Senate or electoral college (and on the negative side, why an inherently flawed partisan system in synch with populist media swings, bowls over rationale-mindedness and diverse opinions). While I agree that my prior implementations were indeed poor (part of learning-in-the-process style which I find wikis can help correct, especially a non-canonical one like Wikia), I still vehemently disagree that such a framework is inherently not "good code", as you seem to have been suggesting. ::::::::: However, that being said, I do recognize that the majority should ultimately prevail (though again, I could still argue that Wikia is not the same kind of forum of neutrality, etc.). What I would request as what I see as a real compromise is to keep both the PHP-JavaScript and category, with disclaimers to the effect that some people feel that the coding style is not appropriate or too specialized for the site, while others feel they are potentially convenient, instructive, and useful, and refer those interested to the articles under my user namespace. I want people to be able to see that the library is here, and be able to contribute to it, rather than believing they have to sheepishly come in through the back door to contribute to a potentially fine concept that they as veterans or amateurs can avail themselves of, if they so decide. You believe it is inherently a poor practice--I certainly do not; democracy does not mean wiping out the opinions of the minority--in Wikipedia as in true democracies, all ideas can be described, albeit there in a neutral point of view. I feel any JavaScript framework-related information (as they indeed pertain to JavaScript) should be able to have a place here (via a link from the main page either to the specific libraries or to a libraries category) and that this one should have no different status. :::: This third is a symptom of a wider problem, viz. that in PHP, as in C, lack of power leads to very poor code being considered acceptable. In Javascript, however, there are facilities for neatly ordering and namespacing methods rather than dumping them all into the global namespace, and as such this quality of code is not considered acceptable. If there really were a necessity for everything to be in the global namespace, the better approach would be the opposite of the one you have taken here: putting everything in appropriate namespaces, and offering a function to 'unpack' it into the global namespace (and preferably one to pack it away again after use, that it might avoid cluttering up said namespace for longer than necessary). ::::: If the point of this Wikia were to instruct newcomers, then I'd agree with this. But the point, from my perspective, was to make things easy and familiar for those who were looking under "PHP-JavaScript". For those familiar with PHP, objects, methods, etc. can be intimidating to start with (not only intimidating, but disjointed looking). Just working with verbs (i.e., functions) is a lot easier for a beginner to grasp and remember. Yes, if you stop learning there, you'll write bad code for a while. But it can get people started and enjoy the immediacy of writing client-side code that their experience with PHP could not provide, inspiring them to study further (and it's not THAT hard to add namespacing later). Besides, when used in environments which support importing of scripts into a namespaced object, the non-namespaced version is easier to read and work with internally. :::::: Again, this is about Javascript, not PHP, nor PHP-JavaScript, nor 'how to hack together a bouncy menu effect, for PHP users who can't be bothered to learn Javascript'. ::::::: Again, the web is not only for snobs. It is also for people with little time, for those with poor memory, and for amateurs (and these are not all the same). And, it is for people who prefer convenience. There is plenty of support in the programming community for sometimes valuing convenience over exactitude. OOP itself is just a convenience. :::::::: There's a difference between convenience and hacks. Convenience can be provided in better ways, such as by all the features that you ignore, like OO and functional programming. As you say, OOP is just a convenience — so if you're going for convenience, why neglect it? ::::::::: There are two issues here. My implementations (which I do need to update) did ignore OO and functional programming because at that time, I had not been aware of how to use them. I fully believe in taking advantage of these features within the implementations, to the extent they are warranted (though I think here, it is probably more of an issue of using the right native functions). But, as far as using the object-style features of JavaScript within my regular code, I see no valid reason why I should not avail myself of the convenience of using PHP notation such as array_merge() or trim(), etc. within my otherwise OO/functional code (as I have been doing, since completing a study of such books as the Definitive Guide to JavaScript, building Firefox extensions, etc.--my column browser uses both OO and functional programming, for example). If I think it is cleaner and easier to remember to write array_merge(arr1, arr2) instead of Array.prototype.concat.call(arr1, arr2) (assuming an efficient implementation), what harm is this doing? Yes, I will hopefully know what the latter does, and try to remember it, but I don't think making life is easy for oneself is a bad thing, assuming it is indeed making one's life easy (using a poor implementation admittedly is not). :::::: It's a Javascript wiki, it was approved under the assumption that it would be a Javascript wiki, and it's been given an URL denoting its purpose as a Javascript wiki. ::::::: Yes. And PHP-JavaScript is JavaScript. Other JavaScript frameworks are welcome too, until such time as they get their own wiki. :::::::: It isn't to do with JavaScript in general, it's a particular JavaScript library. As I've said before, I wouldn't mind, but it degrades the general JavaScript information if it's perceived to be condoned by the same people who wrote the better information. ::::::::: I hope we can refrain from saying different styles are "better". Countless flame wars haven't solved the issue in other fora either. Let's fully express reservations, describe alternatives, and if truly better solutions can be found (e.g., speeding up array_merge()), then let's go with them. We (both you or I) may even find ourselves changing our minds and learning something from one another. :::: Of course you can have a community space for the project; however, I don't think this is the right one. At any rate, you have one here within your user pages with which you can share this information with others, a compromise that I can accept, so I fail to see the problem. :::: — Twey 10:52, 19 October 2008 (UTC) ::::: I have made links on other websites to the PHP-JavaScript page(s) here. If you indeed somehow have the authority to make this decision final and override the founders, I would hope that the PHP-JavaScript link could at least be preserved. And if Wikia could set up a dedicated PHP-JavaScript wiki, I'd be happy to move things there. But as mentioned above, I really think you ought to be asking yourself why you are even contributing to the wiki if your interest is for teaching people about JavaScript, as the MDC (Mozilla Developer Center) has opened itself for this purpose (and is a logical place for it too, having given birth to JavaScript) and would benefit greatly from further contributions. On the other hand, something like PHP-JavaScript or other special-purpose code snippet libraries, I think makes sense at a non-official site like Wikia where people know that its contents are not limited to canonical information. - Brettz9 :::::: And Jesdisciple, in recognition of that, has left a soft redirect for people coming to this site via those links. I choose this wiki because my interest lies in spreading good information about Javascript to combat all the bad out there, especially for the newbies, but this does not necessarily mean that all the information will be canonical, and it certainly won't be focussed on one particular implementation as would be encouraged at MDC. Additionally, I would prefer to set it up here because a wiki should be community-driven, with admins interfering as little as possible, which I don't think is the case in MDC. A wiki is a free repository of information, and is not meant to be the playground or personal hosting grounds of one or two founders or authority figures. While some may necessarily have more power than others, everybody should have equal authority. ::::::: Funny you say that, since your words seem to fly in the face of that. But, anyways, I think your rationale is reasonable. I'm personally not too happy with the transition at MDC away from Mediawiki (maybe we can get an old dump of the site to build off of, to the extent the licenses would be compatible). :::::::: I don't see how. I am arguing for democracy and equal authority (two out of three people have agreed that this code should not be seen to be officially condoned). Having a dump of MDC would be interesting, but I'm not sure if it might not be difficult to integrate: the structure must be considerably different, I suspect. ::::::::: Well, if you really want to undertake the ambitious work of fully competing with MDC, if not actually porting the pages, then at least linking to them from time to time, in order to find information to draw upon may, I think, be helpful for some. :::::: I have to ask if perhaps you'd be better off with a static website than a wiki, since the idea of a free repository of quality Javascript-oriented information seems to be somewhat inimicable to your goals here. :::::: — Twey 16:02, 19 October 2008 (UTC) ::::::: Just as you have your reasons, I have mine. I think a community can improve the quality of the functions, as your pointing out the speed problem did. :::::::: You can have a community without a wiki. You might, for example, provide a comment box for suggestions, or even a whole forum. This would allow you to keep tight control over it and veto such changes, like this one, that you found undesirable. :::::::: — Twey 16:25, 21 October 2008 (UTC) ::::::::: I want a wiki. The PHP-JavaScript blogger already allows comments. Like you, I also believe in the democratic process by which everyone can contribute, and I don't feel a blog/discussion forum leads to optimum results (though with their project being generously under the MIT license and actively maintained by knowledgeable persons, I would certainly like to port all of their content here as a base). The changes I don't favor in a wiki, especially a non-narrowly focused site like Wikia, are those related to entirely removing or displacing others' work, unless it is truly inappropriate. My feeling is that if someone took the time to compile something, it is obviously important enough to them and as a result, often so for others as well, and I'm not inclined to interfere with it. ::::::::::The only way I will support the existence of this section in the main namespace is with explicit disclaimers at the top of every page. I have no problem with the content itself; I just want visitors to seriously consider whether it's a good idea. The disclaimers don't have to outright condemn it as they do now, but they should cast definite doubt on it. --Jesdisciple (talk) 04:50, 22 October 2008 (UTC) :::::::Brettz9, I deeply regret that these decisions need to be made at all, and I understand your frustration; indeed, part of me screams "Traitor!" So what are all the incoming links you have posted? Those pages can work similarly to PHP-Javascript, and I think a template is appropriate. :::::::If you have any other important points which you would like me to respond to, please say so. (I was going to address why we don't use MDC, but Twey got it.) --Jesdisciple (talk) 16:32, 19 October 2008 (UTC) :::::::: Respectfully, Jesdisciple, shouldn't this decision have been collaborative? I believe I still am the co-founder here. :::::::::You're right; I messed that up even without your status. I did intend to collaborate, but you never showed up at the category talk (you probably just missed the note that the discussion was moving there) and I should have been more proactive about the collaboration. What changes do you propose? (Note that the overall decision is the result of consensus, even if it's slim.) --Jesdisciple (talk) 01:27, 21 October 2008 (UTC) :::::::::: Fair enough (interesting that the reason I can't as easily visit the site from where I am is also related to a view of what can be discussed or not, eh?!). As I mentioned above, I've proposed a compromise which I hope you both can consider. :)